This chapter describes risk management, which is a technique used to mitigate risk when implementing an architecture project.

Introduction

There will always be risk with any architecture/business transformation effort. It is important to identify, classify, and mitigate these risks before starting so that they can be tracked throughout the transformation effort.

Mitigation is an ongoing effort and often the risk triggers may be outside the scope of the transformation planners (e.g., merger, acquisition) so planners must monitor the transformation context constantly.

It is also important to note that the enterprise architect may identify the risks and mitigate certain ones, but it is within the governance framework that risks have to be first accepted and then managed.

There are two levels of risk that should be considered, namely:

1. Initial Level of Risk: Risk categorization prior to determining and implementing mitigating actions.
2. Residual Level of Risk: Risk categorization after implementation of mitigating actions (if any).

The process for risk management is described in the following sections and consists of the following activities:

• Risk classification
• Risk identification
• Initial risk assessment
• Risk mitigation and residual risk assessment
• Risk monitoring

Risk Classification

Risk is pervasive in any enterprise architecture activity and is present in all phases within the Architecture Development Method (ADM). From a management perspective, it is useful to classify the risks so that the mitigation of the risks can be executed as expeditiously as possible.

One common way for risks to be classified is with respect to impact on the organization (as discussed in Initial Risk Assessment), whereby risks with certain impacts have to be addressed by certain levels of governance.

Risks are normally classified as time (schedule), cost (budget), and scope but they could also include client transformation relationship risks, contractual risks, technological risks, scope and complexity risks, environmental (corporate) risks, personnel risks, and client acceptance risks.

Other ways of delegating risk management is to further classify risks by architecture domains. Implementation risk is often quoted, but that is almost always the case. Classifying risks as business, information, applications, and technology is useful but there may be organizationally-specific ways of expressing risk that the corporate enterprise architecture directorate should adopt or extend rather than modify.

Ultimately, enterprise architecture risks are corporate risks and should be classified and as appropriate managed in the same or extended way.

Risk Identification

The maturity and transformation readiness assessments will generate a great many risks. Identify the risks and then determine the strategy to address them throughout the transformation.

The use of Capability Maturity Models (CMMs) is suitable for specific factors associated with architecture delivery to first identify baseline and target states and then identify the actions required to move to the target state. The implications of not achieving the target state can result in the discovery of risks. Refer to Business Transformation Readiness Assessment for specific details.

Risk documentation is completed in the context of a Risk Management Plan, for which templates exist in standard project management methodologies (e.g., Project Management Book of Knowledge and PRINCE2) as well as with the various government methodologies.

Normally these methodologies involve procedures for contingency planning, tracking and evaluating levels of risk; reacting to changing risk level factors, as well as processes for documenting, reporting, and communicating risks to stakeholders.

Initial Risk Assessment

The next step is to classify risks with respect to effect and frequency in accordance with scales used within the organization. Combine effect and frequency to come up with a preliminary risk assessment.

There are no hard and fast rules with respect to measuring effect and frequency. The following guidelines are based upon existing risk management best practices. Effect could be assessed using the following example criteria:

• Catastrophic infers critical financial loss that could result in bankruptcy of the organization.
• Critical infers serious financial loss in more than one line of business leading to a loss in productivity and no return on investment on the IT investment.
• Marginal infers a minor financial loss in a line of business and a reduced return on investment on the IT investment.
• Negligible infers a minimal impact on a line of business' ability to deliver services and/or products.

Frequency could be indicated as follows:

• Frequent: Likely to occur very often and/or continuously.
• Likely: Occurs several times over the course of a transformation cycle (possibly once every 36 months).
• Occasional: Occur sporadically (not more than once per year).
• Seldom: Remotely possible and would probably occur not more than once in the course of the entire transformation.
• Unlikely: Will probably not occur during the transformation effort.

Combining the two factors to infer impact would be conducted using a heuristically-based but consistent classification scheme for the risks. A potential scheme to assess corporate impact could be as follows:

• Extremely High Risk (E): The transformation effort will most likely fail with severe consequences.
• High Risk (H): Significant failure of parts of the transformation effort resulting in certain goals not being achieved.
• Moderate Risk (M): Noticeable failure of parts of the transformation effort threatening the success of certain goals.
• Low Risk (L): Certain goals will not be wholly successful.

These impacts can be derived using a classification scheme, as shown in Risk Classification Scheme.

Risk Mitigation and Residual Risk Assessment

Risk mitigation refers to the identification, planning, and conduct of actions that will reduce the risk to an acceptable level.

The mitigation effort could be a simple monitoring and/or acceptance of the risk to a full-blown contingency plan calling for complete redundancy in a Business Continuity Plan (with all of the associated scope, cost, and time implications).

Due to the implications of this risk assessment, it has to be conducted in a pragmatic but systematic manner. With priority going to frequent high impact risks, each risk has to be mitigated in turn.

Conduct Residual Risk Assessment

Once the mitigation effort has been identified for each one of the risks, re-assess the effect and frequency and then recalculate the impacts and see whether the mitigation effort has really made an acceptable difference. The mitigation efforts will often be resource-intensive and a major outlay for little or no residual risk should be challenged.

Once the initial risk is mitigated, then the risk that remains is called the "residual risk". The key consideration is that the mitigating effort actually reduces the corporate impact and does not just move the risk to another similarly high quadrant. For example, changing the risk from frequent/catastrophic to frequent/critical still delivers an Extremely high risk. If this occurs, then the mitigation effort has to be re-considered.

The final deliverable should be a transformation risk assessment that could be structured as a worksheet, as shown in Sample Risk Identification and Mitigation Assessment Worksheet.

Risk Monitoring and Governance (Phase G)

The residual risks have to be approved by the IT governance framework and potentially in corporate governance where business acceptance of the residual risks is required.

Once the residual risks have been accepted, then the execution of the mitigating actions has to be carefully monitored to ensure that the enterprise is dealing with residual rather than initial risk.

The risk identification and mitigation assessment worksheets are maintained as governance artifacts and are kept up-to-date in Phase G (Implementation Governance) where risk monitoring is conducted.

Implementation governance can identify critical risks that are not being mitigated and might require another full or partial ADM cycle.

Summary

Risk Management is an integral part of enterprise architecture. Practitioners are encouraged to use their corporate risk management methodology or extend it using the guidance in this chapter. In the absence of a formal corporate methodology, architects can use the guidance in this chapter as a best practice.